Intro to Scheduling

We now know how the Operating System facilitates the sharing of a core among many processes. The next question is which process to run.

At first glace, the answer may be obvious.

• What do you think it is?

But, there is some unexpected subtlety here.

• Any guesses as to why the simple answer isn’t good enough?

Beginning Assumptions (to be relaxed as we go):

1. Each job runs for the same amount of time
2. All jobs arrive at the same time
3. One started, each job runs to completion
4. All jobs use CPU only
5. The run-time of each job is known.

(Not realistic; but, helpful to keep things simple as we get started.)

(Basically, deciding what order to do the work in.)

Scheduling Metrics

• Suggest some metrics to decide if a schedule is “good”.
  • Average turnaround time (arrival to completion)
  • Fairness
  • Response time (only applies to interactive)

Schedules

• Suggest some scheduling algorithms
  • FIFO
  • SJF
• SJF is optimal.
  • Why? Make an informal argument
  • To be clear: The total time to get all jobs done is the same. However, imagine each job has a different “client”. How do we make our clients as a whole as happy as possible.
  • (Imagine there are 100 1s jobs and 1 10000s jobs. Putting the 1000s job last means that only one person has to wait that 1000s)
• We can generalize this by allowing preemption.
  • Called STCF (Shortest Time to Completion First) or Preemptive SJF
  • Also optimal
• Now, lets consider interactive jobs.
• STCF not good:
  • Why?
  • Can leave people waiting a long time.
• So, what do we do? How do we measure what we want?
• New metric: Response time (time to scheduled instead of time to completion)

Round Robin

• Switch every x seconds.
• The faster you switch, the shorter the response time.
• So, how fast should you switch?
• What is the problem with making the time slice too short?
  • Switching processes has an overhead. The more often you switch, the less time your CPU is doing “useful” work.
• The time needed for a context switch is independent of the time slice
• Increasing the time slices amortizes the cost over more “real” work.
• Cost of context switch is more than just the time needed to execute the switch
  • Invalidated caches
  • Invalidated TLBs
  • Branch predictors
• Notice that there is a tradeoff between minimizing turnaround time and response time
  • Need to define a balance between overall system efficiency and the happiness and efficiency of the users.

Consider I/O

• Relax assumption 4 above: Process now alternate between using the CPU and waiting on I/O.
  • Explain just how slow I/O is (in terms of instructions).
• Processes should give up the CPU when waiting on I/O.
  • Consider the case of a process that uses CPU for 10ms, then waits 10ms for I/O. We can double utilization if we “fill in the gaps”
  • Show Figure 7.9 https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf

Thinking ahead:

• How can we balance the benefits of STCF and round robin (both metrics and algorithms)?
• How do we handle the fact that we don’t know how long jobs will run?

https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf